Как оказалось у нас на сайте нет инструкции по подключению локальных дисков сервера VMware ESXi в качестве RDM-дисков для виртуальных машин. Восполняем этот пробел. Как известно, если вы попытаетесь добавить локальный диск сервере ESXi в качестве RDM-тома для ВМ, вы там его не увидите:

Связано это с тем, что VMware не хочет заморачиваться с поддержкой дисков различных производителей, где будут размещены производственные виртуальные машины. Поэтому нам нужно создать маппинг-файл VMDK на локальное дисковое устройство, который уже как диск (pRDM или vRDM) подключить к виртуальной машине.

Для начала найдем имя устройства локального SATA-диска в списке устройств ESXi. Для этого перейдем в соответствующую директорию командой:

# cd /dev/disks

И просмотрим имеющиеся диски:

# ls -l

Нас интересуют те диски, что выделены красным, где вам необходимо найти свой и скопировать его имя, вроде t10.ATA___....__WD2DWCAVU0477582.

Далее переходим в папку с виртуальной машиной, которой мы хотим подцепить диск, например:

# cd /vmfs/volumes/datastore1/<vm name>

И создаем там маппинг VMDK-диск для создания RDM-тома, при этом можно выбрать один из режимов совместимости:

Для pRDM (Physical RDM):

# vmkfstools -z /vmfs/devices/disks/<имя t10.ATAитп> rdm_WD2DWCAVU0477582.vmdk

Для vRDM (Virtual RDM):

# vmkfstools -r /vmfs/devices/disks/<имя t10.ATAитп> rdm_WD2DWCAVU0477582.vmdk

После того, как vmdk mapping file создан, можно цеплять этот диск к виртуальной машине через Add Virtual Disk (лучше использовать для него отдельный SCSI Controller):

Второй способ, который работает не для всех дисков - это отключение фильтра на RDM-диски (это можно сделать и на сервере VMware vCenter). Для этого в vSphere Client для хоста ESXi нужно пойти сюда:

Configuration > Software > Advanced Settings > RdmFilter

Там и выставляется соответствующая галочка:

Однако, повторимся, этот метод (в отличие от первого) работает не всегда. Ну и учитывайте, что подобная конфигурация не поддерживается со стороны VMware, хотя и работает.

В конце июня мы писали про технологическое превью продукта VMware Workstation 2012 (плюс тут), в котором появилось новое средство WSX Server - возможность прямого доступа к консоли виртуальной машины из браузера без каких-либо плагинов.

Напомним, что WSX Server, который есть в VMware Workstation 2012, работает на базе технологии HTML 5 (с поддержкой WebSockets и Canvas), что подразумевает отсутствие необходимости иметь какие-либо дополнительные компоненты, кроме веб-браузера, чтобы получить доступ к консоли виртуальной машины и средствами управления ей. В качестве веб-браузеров, той или иной степени совместимых с HTML 5, можно использовать Chrome 17, Firefox 10, IE 10, Safari 5 на ПК с Mac OS и iOS 5 для iPad. Также стоит отметить, что VMware WSX поддерживает новые iPad с дисплеем Retina.

Итак, основные июльские нововведения технологии WSX:

• Улучшенная домашняя страница - теперь на ней есть возможность добавлять серверы в список, также на нее будет возможность добавить часто используемые ВМ

• Улучшенная страница при выборе сервера WSX - теперь виртуальные машины можно фильтровать по состоянию (powered on и т.п.), а также есть поиск

• Большая кнопка "Включить ВМ" - удобна для iPad'ов:

• Улучшенный Touch Input - для планшетов и смартфонов поддерживаются жесты, которыми можно эмулировать не только правую кнопку мыши (нажать и подержать пальцем), но и среднюю. Если держать одновременно двумя пальцами и тащить вниз или вверх - будет скроллинг.
• Поддержка колесика мыши - работает в браузерах на PC и Mac.
• Улучшен механизм работы с дисплеями Retina - теперь WSX не вываливается в пониженное разрешение при повторном соединении после обрыва. Дорисованы новые иконки и пофикшены баги.
• Поддержка шифрованного SSL-соединения. Теперь можно назвать сертификаты именами wsx.crt и wsx.key и положить их в папки etc/vmware/wsx/ssl/directory (Linux) или Application Data\VMware\VMware WSX\SSL (Windows). Этого не сделано по умолчанию, так как SSL глючит с WebSockets.
• Упрощенная установка - для Linux, например, больше не требуется Python. Для Windows улучшили стабильность.
• Улучшенное обнаружение общих виртуальных машин (Shared VMs).
• Улучшения производительности - при соединении и изменении разрешения.
• Множественные исправления ошибок.

Напомним, что функции WSX работают, по-прежнему, в экспериментальном режиме.

Более подробно о VMware Workstation 2012 TP June можно прочитать на странице ведущего разработчика, а также на официальной странице обновленного продукта. Скачать VMware Workstation 2012 TP June вместе с компонентами WSX можно по этой ссылке.

Мы уже касались некоторых аспектов мониторинга производительности с помощью утилиты esxtop, которая есть на сервере VMware ESXi, а также метрик производительности хранилищ (и немного сетевого взаимодействия). Сегодня мы более детально взглянем на метрики производительности процессора (CPU) для контроля нагрузки виртуальных машин.

Если мы запустим утилиту esxtop, то увидим следующие столбцы (интересующее нас выделено красным):

Нас интересует 5 счетчиков, касающиеся процессоров виртуальных машин, с помощью которых мы сможем сделать выводы об их производительности. Рассмотрим их подробнее:

Счетчик %RUN

Этот счетчик отображает процент времени, в течение которого виртуальная машина исполнялась в системе. Когда этот счетчик для ВМ около нуля или принимает небольшие значение - то с производительностью процессора все в порядке (при большом его значении для idle). Однако бывает так, что он небольшой, а виртуальная машина тормозит. Это значит, что она заблокирована планировщиком ESXi или ей не выделяется процессорного времени в связи с острой нехваткой процессорных ресурсов на сервере ESXi. В этом случае надо смотреть на другие счетчики (%WAIT, %RDY и %CSTP).

Если значение данного счетчика равно <Число vCPU машины> x 100%, это значит, что в гостевой ОС виртуальной машины процессы загрузили все доступные процессорные ресурсы ее vCPU. То есть необходимо зайти внутрь ВМ и исследовать проблему.

Счетчики %WAIT и %VMWAIT

Счетчик %WAIT отображает процент времени, которое виртуальная машина ждала, пока ядро ESXi (VMkernel) выполняло какие-то операции, перед тем, как она смогла продолжить выполнение операций. Если значение этого счетчика значительно больше значений %RUN, %RDY и %CSTP, это значит, что виртуальная машина дожидается окончания какой-то операции в VMkernel, например, ввода-вывода с хранилищем. В этом случае значение счетчика %SYS, показывающего загрузку системных ресурсов хоста ESXi, будет значительно выше значения %RUN.

Когда вы видите высокое значение данного счетчика, это значит, что нужно посмотреть на производительность хранилища виртуальной машины, а также на остальные периферийные устройства виртуального "железа". Зачастую, примонтированный ISO-образ, которого больше нет на хранилище, вызывает высокое значение счетчика. Это же касается примонтированных USB-флешек и других устройств ВМ.

Не надо пугаться высокого значения %WAIT, так как оно включает в себя счетчик %IDLE, который отображает простой виртуальной машины. А вот значение счетчика %VMWAIT - уже более реальная метрика, так как не включает в себя %IDLE, но включает счетчик %SWPWT (виртуальная машина ждет, пока засвопированные таблицы будут прочитаны с диска; возможная причина - memory overcommitment). Таким образом, нужно обращать внимание на счетчик %VMWAIT. К тому же, счетчик %WAIT представляет собой сумму метрик различных сущностей процесса виртуальной машины:

Счетчик %RDY

Главный счетчик производительности процессора. Означает, что виртуальная машина (гостевая ОС) готова исполнять команды на процессоре (ready to run), но ожидает в очереди, пока процессоры сервера ESXi заняты другой задачей (например, другой ВМ). Является суммой значений %RDY для всех отдельных виртуальных процессоров ВМ (vCPU). Обращать внимание на него надо, когда он превышает пороговое значение 10%.

По сути, есть две причины, по которым данный счетчик может зашкаливать приведенное пороговое значение:

• сильная нагрузка на физические процессоры из-за большого количества виртуальных машин и нагрузок в них (здесь просто надо уменьшать нагрузку)
• большое количество vCPU у конкретной машины. Ведь виртуальные процессоры машин на VMware ESX работают так: если у виртуальной машины 4 vCPU, а на хосте всего 2 физических pCPU, то одна распараллеленная операция (средствами ОС) будет исполняться за в два раза дольший срок. Естественно, 4 и более vCPU для виртуальной машины может привести к существенным задержкам в гостевой ОС и высокому значению CPU Ready. Кроме того, в некоторых случаях нужен co-sheduling нескольких виртуальных vCPU (см. комментарии к статье), когда должны быть свободны столько же pCPU, это, соответственно, тоже вызывает задержки (с каждым vCPU ассоциирован pCPU). В этом случае необходимо смотреть значение счетчика %CSTP

Кроме того, значение счетчика %RDY может быть высоким при установленном значении CPU Limit в настройках виртуальной машины или пула ресурсов (в этом случае посмотрите счетчик %MLMTD, который при значении больше 0, скорее всего, говорит о достижении лимита). Также посмотрите вот этот документ VMware.

Счетчик %CSTP

Этот счетчик отображает процент времени, когда виртуальная машина готова исполнять команды, одна вынуждена ждать освобождения нескольких vCPU при использовании vSMP для одновременного исполнения операций. Например, когда на хосте ESXi много виртуальных машин с четырьмя vCPU, а на самом хосте всего 4 pCPU могут возникать такие ситуации с простоем виртуальных машин для ожидания освобождения процессоров. В этом случае надо либо перенести машины на другие хосты ESXi, либо уменьшить у них число vCPU.

В итоге мы получаем следующую формулу (она верна для одного из World ID одной виртуальной машины)

%WAIT + %RDY + %CSTP + %RUN = 100%

То есть, виртуальная машина либо простаивает и ждет сервер ESXi (%WAIT), либо готова исполнять команды, но процессор занят (%RDY), либо ожидает освобождения нескольких процессоров одновременно (%CSTP), либо, собственно, исполняется (%RUN).

Мы уже не раз писали о различных типах очередей ввода-вывода, присутствующих на различных уровнях в VMware vSphere, в частности, в статье "Глубина очереди (Queue Depth) и адаптивный алгоритм управления очередью в VMware vSphere". Недавно на блогах компании VMware появился хороший пост, упорядочивающий знания об очередях ввода-вывода на различных уровнях виртуальной инфраструктуры.

Если речь идет о виртуальных машинах на сервере VMware ESXi, работающих с дисковым массивом, можно выделить 5 видов очередей:

• GQLEN (Guest Queue) - этот вид очередей включает в себя различные очереди, существующие на уровне гостевой ОС. К нему можно отнести очереди конкретного приложения, очереди драйверов дисковых устройств в гостевой ОС и т.п.
• WQLEN (World Queue/ Per VM Queue) - это очередь, существующая для экземпляра виртуальной машины (с соответствующим World ID), которая ограничивает единовременное число операций ввода-вывода (IOs), передаваемое ей.
• AQLEN (Adapter Queue) - очередь, ограничивающая одновременное количество обрабатываемых на одном HBA-адаптере хоста ESXi команд ввода вывода.
• DQLEN (Device Queue / Per LUN Queue) - это очередь, ограничивающая максимальное количество операций ввода-вывода от хоста ESXi к одному LUN (Datastore).
• SQLEN (Storage Array Queue) - очередь порта дискового массива (Storage Processor, SP)

Эти очереди можно выстроить в иерархию, которая отражает, на каком уровне они вступают в действие:

Очереди GQLEN бывают разные и не относятся к стеку виртуализации VMware ESXi, поэтому мы рассматривать их не будем. Очереди SQLEN мы уже частично касались тут и тут. Если до SP дискового массива со стороны сервера ESX / ESXi используется один активный путь, то глубина очереди целевого порта массива (SQLEN) должна удовлетворять следующему соотношению:

SQLEN>= Q*L

где Q - это глубина очереди на HBA-адаптере, а L - число LUN, обслуживаемых SP системы хранения. Если у нас несколько активных путей к одному SP правую часть неравенства надо еще домножить на P - число путей.

Соответственно, в виртуальной инфраструктуре VMware vSphere у нас несколько хостов имеют доступ к одному LUN через его SP и получается следующее соотношение:

SQLEN>= ESX1 (Q*L*P) + ESX2 (Q*L*P)+ и т.д.

Теперь рассмотрим 3 оставшиеся типа очередей, которые имеют непосредственное отношение к хосту VMware ESXi:

Как мы видим из картинки - очереди на различных уровнях ограничивают число I/O, которые могут быть одновременно обработаны на различных сущностях:

• Длина очереди WQLEN по умолчанию ограничена значением 32, что не позволяет виртуальной машине выполнять более 32-х I/O одновременно.
• Длина очереди AQLEN - ограничена значением 1024, чтобы собирать в себя I/O от всех виртуальных машин хоста.
• Длина очереди DQLEN - ограничена значением 30 или 32, что не позволяет "выедать" одному хосту ESXi с одного хранилища (LUN) более 30-ти или 32-х операций ввода-вывода

Все эти очереди можно посмотреть с помощью esxtop:

Зачем вообще нужны очереди? Очень просто - очередь это естественный способ ограничить использование общего ресурса. То есть одна виртуальная машина не заполонит своими командами ввода-вывода весь HBA-адаптер, а один хост ESXi не съест всю производительность у одного Datastore (LUN), так как ограничен всего 32-мя I/O к нему.

Мы уже писали о функционале Storage I/O Control (SIOC), который позволяет регулировать последний тип очереди, а именно DQLEN, что позволяет корректно распределить нагрузку на СХД между сервисами в виртуальных машинах в соответствии с их параметрами shares (эта функциональность есть только в издании vSphere Enterprise Plus). Механизм Storage IO Control для хостов VMware ESX включается при превышении порога latency для тома VMFS, определяемого пользователем. Однако, стоит помнить, что механизм SIOC действует лишь в пределах максимально определенного значения очереди, то есть по умолчанию не может выйти за пределы 32 IO на LUN от одного хоста.

Для большинства случаев этого достаточно, однако иногда требуется изменить обозначенные выше длины очередей, чтобы удовлетворить требования задач в ВМ, которые генерируют большую нагрузку на подсистему ввода-вывода. Делается это следующими способами:

1. Настройка длины очереди WQLEN.

Значение по умолчанию - 32. Его задание описано в статье KB 1268. В Advanced Settings хоста ESXi нужно определить следующий параметр:

Disk.SchedNumReqOutstanding (DSNRO)

Он глобально определяет, сколько операций ввода-вывода (IOs) может максимально выдать одна виртуальная машина на LUN одновременно. В то же время, он задает это максимальное значение в IOs для всех виртуальных машин на этот LUN от хоста ESXi (это глобальная для него настройка). То есть, если задано значение 32, то все машины могут одновременно выжать 32 IOs, это подтверждается в случае, где 3 машины генерируют по 32 одновременных IO к одному LUN, а реально к LUN идут все те же 32, а не 3*32.

2. Настройка длины очереди AQLEN.

Как правило, этот параметр менять не требуется, потому что дефолтного значения 1024 хватает практически для всех ситуаций. Где его менять, я не знаю, поэтому если знаете вы - можете написать об этом в комментариях.

3. Настройка длины очереди DQLEN.

Настройка этого параметра описана в KB 1267 (мы тоже про это писали) - она зависит от модели и драйвера HBA-адаптера (в KB информация актуальна на июнь 2010 года). Она взаимосвязана с настройкой Disk.SchedNumReqOutstanding и, согласно рекомендациям VMware, должна быть эквивалентна ей. Если эти значения различаются, то когда несколько ВМ используют с хоста ESXi один LUN - актуальной длиной очереди считается минимальное из этих значений.

Для отслеживания текущих значений очередей можно использовать утилиту esxtop, как описано в KB 1027901.

Для тех, кто активно использует инфраструктуру виртуальных ПК на базе решения VMware View, на сайте проекта VMware Labs появился интересный скрипт - View Controlled Recompose Script. Как знают пользователи VMware View, при необходимости обновления десктопов можно сделать операцию "Recompose", где, выбрав обновленный снапшот базовой ВМ или другую базовую ВМ, можно перестроить виртуальные машины пользователей пула ПК на работу с новым диском, не затрагивая диск с пользовательскими данными:

В отличие от стандартых средств по рекомпозиции в VMware View Manager, в скрипте View Controlled Recompose производится интеллектуальная процедура: через интерфейс WMI производится определение неиспользуемых виртуальных машин, после чего один из таких десктопов используется как реплика (Replica VM), а далее для неиспользуемых десктопов происходит рекомпозиция на базе этой реплики. Потом для активных десктопов можно сделать Force Logoff и перенаправить пользователей на уже рекомпозированные виртуальные ПК, а для этих активных десктопов, в свою очередь, доделать рекомпозицию.

По умолчанию скрипт работает в интерактивном режиме и принимает следующие входные параметры:

• Pool - пул виртуальных ПК для рекомпозиции
• ParentVM - полный путь к базовому образу
• NewSnapshot - полный путь к снапшоту образа, из которого будет создаваться реплика и делаться рекомпозиция

Скрипт необходимо запускать на сервере VMware View Connection Server, сам же скрипт сделан на PowerCLI / PowerShell. Более подробные инструкции по его использованию приведены по этой ссылке.

Скачать скрипт VMware View Controlled Recompose Script можно по этой ссылке.

Не так давно компания Microsoft опубликовала окончательную модель лицензирования нового поколения семейства серверных ОС Windows Server 2012, где достаточно существенно поменялись правила лицензирования ОС под виртуализацию.

Напомним, как обстояли дела с лицензированием операционных систем Windows Server 2008 R2:

Как видно из таблицы лицензия на издание Windows Server 2008 R2 Standard давала право на запуск одной хостовой машины и одной виртуальной, издание Enterprise - возможность запуска 4-х экземпляров под одной лицензией плюс хостовая платформа, а издание Datacenter позволяло запускать неограниченное количество экземпляров виртуальных машин в пределах одного лицензированного сервера.

Недавно мы уже упоминали о том, что для продукта Microsoft System Center 2012 Suite уже было убрано издание Enterprise, теперь же пришла очередь Windows Server 2012 лишиться этого издания. Теперь в новой ОС, с точки зрения виртуализации, осталось лишь 2 издания - Standard и Datacenter:

Издания Essentials и Foundation не предполагают каких-либо прав на виртуализацию и предназначены для совсем малых предприятий, поэтому здесь мы их рассматривать не будем, а сфокусируемся на изданиях Standard и Datacenter. Обратите также внимание, что исчезло издание Web Server Edition.

Во-первых, издание Windows Server 2012 Standard ничем не отличается по функциональности от издания Datacenter (Full Windows Server functionality), а поэтому оно подорожало. А именно в издании Windows Server 2012 Standard появилась следующая функциональность, которой не было в Windows Server 2008 R2:

• Windows Server Failover Clustering
• BranchCache Hosted Cache Server
• Active Directory Federated Services
• Additional Active Directory Certificate Services capabilities
• Distributed File Services (support for more than 1 DFS root)
• DFS-R Cross-File Replication

Соответственно, с точки зрения функционала мы имеем, по-сути, одно издание данной ОС. А дифференцируются эти издания следующим образом: Standard позволяет запустить до 2-х виртуальных машин под одной лицензией, а издание Datacenter - неограниченное количество ВМ.

Одна лицензия Windows Server 2012 Standard или Datacenter приобретается на 2 процессора физического хост-сервера. Таким образом, если у вас 4-процессорный сервер, вы можете:

• купить 2 лицензии Windows Server 2012 Standard и запустить 4 виртуальные машины на нем (неважно на платформе Microsoft Hyper-V или VMware vSphere)
• купить 2 лицензии Windows Server 2012 Datacenter и запускать сколько угодно виртуальных машин на нем (Hyper-V или vSphere)

Понятно, что 4 виртуальные машины на четырехпроцессорном сервере никто исполнять не будет, поэтому в случае увеличения количества ВМ на сервере можно пойти двумя путями, в зависимости от экономической целесообразности. Например, вы приобрели 2 лицензии на Windows Server 2012 Standard (1 лицензия = 2 CPU сервера) на четырехпроцессорный сервер, и у вас виртуальных машин стало больше четырех (т.е. больше того, что позволяет лицензия). В этом случае вы можете:

• Докупить еще лицензий на Windows Server 2012 Standard, каждая из которых позволит дополнительно запускать по 2 виртуальные машины на данном сервере
• Если у вас есть действующая подписка Software Assurance, можно сделать Software Assurance Step-Up апгрейд на Datacenter Edition и уже запускать сколько угодно виртуальных машин на этом сервере

Рассмотрим примеры:

1. У вас есть один двухпроцессорный сервер, на котором будет запущено 10 виртуальных машин и вам больше не потребуется увеличивать их количество на этом сервере. Посчитаем стоимость покупки Standard и Datacenter на этот сервер:

• 5 лицензий (каждая на 2 CPU хоста) на Windows Server 2012 Standard дают право исполнять 10 виртуальных машин и стоят 5 х 882 = $4 410
• 1 лицензия (на 2 CPU) на Windows Server 2012 Datacenter дает право исполнять эти 10 виртуальных машин и стоит $4 809

В этом случае лицензии на Windows Server 2012 Standard получается покупать выгоднее.

2. У вас есть один четырехпроцессорный сервер, на котором будет запущено 30 виртуальных машин. Посчитаем стоимость покупки Standard и Datacenter на этот сервер:

• 15 лицензий Standard (на 30 машин) обойдутся в: 15 х 882 = $13 230
• 2 лицензии Datacenter (на 4 CPU) обойдется в: 2 х 4 809 = $9 618

В этом случае уже выгоднее издание Windows Server 2012 Datacenter.

Общее правило для издания Standard таково - сначала вы покрываете требуемыми лицензиями все физические процессоры (сокеты), а далее докупаете лицензии на 2 виртуальные машины. То есть, для 10-процессорного сервера нужно купить минимум 5 лицензий, а для 20 виртуальных машин (неважно сколько физ. процессоров у хоста, если оно меньше 20) - минимум 10 лицензий.

Таким образом, все просто - если маленький коэффициент консолидации ВМ на хосте - нужно покупать Standard, если большой - Datacenter. При этом различия в функциональности нет.

Про даунгрейд с 2012 на 2008 R2 тоже все достаточно понятно. Можно сделать даунгрейд Datacenter на Datacenter, а Standard на Enterprise или Standard, при этом правила лицензирования виртуальных машин остаются от купленного Windows Server 2012:

Правила обмена лицензий Windows Server 2008 R2 на лицензии Windows Server 2012

Правила эти просты:

• каждая лицензия Windows Server 2008 R2 Enterprise (с действующей подпиской Software Assurance) обменивается на 2 лицензии Windows Server 2012 Standard (т.е. всего на 4 ВМ - как и было раньше).
• лицензия Standard 2008 R2 обменивается на Standard 2012 в соотношении 1 к 1.
• лицензия Datacenter 2012 покрывает 2 процессора, а Datacenter 2008 R2 - один процессор, поэтому за две старых 2008 R2 дают одну новую Datacenter 2012.

Более детальная информация представлена в документе "Windows Server 2012 Licensing & Pricing FAQ".

Виктор прислал мне презентацию от того самого Ивана, который на одной из юзер-групп VMware рассматривал особенности дизайна и проектирования виртуальной инфраструктуры VMware vSphere. Часть, касающаяся виртуализации различных типов нагрузок в гостевых ОС виртуальных машин показалась мне очень интересной, поэтому я решил перевести ее и дополнить своими комментариями и ссылками. Итак, что следует учитывать при переносе и развертывании различных приложений в виртуальных машинах на платформе vSphere.

Компания Microsoft недавно выпустила бета-версию решения Microsoft Virtual Machine Converter (Solution Accelerator) (MVMC), которое позволяет конвертировать виртуальные машины из формата VMware vSphere в формат Microsoft Hyper-V. Напомним, что ранее для целей конвертации виртуальных дисков ВМ из формата VMDK в VHD можно было использовать бесплатный 5Nine V2V Easy Converter (кроме того, мы писали о продукте 5nine Migrator for Hyper-V для P2V) и также бесплатный StarWind V2V Converter.

Однако вышедший Microsoft Virtual Machine Converter - это единственное поддерживаемое со стороны MS решение для конверсии VMDK2VHD на платформу Hyper-V. Само собой, конвертируется не только виртуальный диск, но и вся машина в целом.

Конвертация виртуальной машины происходит с простоем ВМ, так как MVMC делает ее снапшот, сносит VMware Tools и драйверы, затем копирует исходный виртуальный диск, после чего откатывает снапшот ВМ.

Microsoft Virtual Machine Converter поддерживает V2V-конвертацию виртуальных машин со следующих платформ VMware:

• VMware vSphere 5.0 (vCenter / ESX / ESXi 5.0)
• VMware vSphere 4.1 (vCenter / ESX / ESXi 4.1)

В качестве хоста назначения могут быть использованы следующие платформы:

• Windows Server 2008 R2 SP1 с ролью Hyper-V (+ Server Core)
• Hyper-V Server 2008 R2 SP1

Для конвертации поддерживаются следующие гостевые ОС:

• Windows Server 2003 SP2 Web, Standard, Enterprise и Datacenter (x86+x64)
• Windows 7 Enterprise (x86+x64)
• Windows Server 2008 R2 SP1 Web, Standard, Enterprise, Datacenter.

Поддержка семейства Windows Server 8 в бета-версии MVMC отсутствует. Документацию по Microsoft Virtual Machine Converter можно загрузить по этой ссылке. Тем, кому необходима P2V-миграция от Microsoft, следует использовать Microsoft P2V Migration Tool.

Компания VMware в базе знаний опубликовала интересный плакат "VMware vSphere 5 Memory Management and Monitoring diagram", раскрывающий детали работы платформы VMware vSphere 5 с оперативной памятью серверов. Плакат доступен как PDF из KB 2017642:

Основные техники оптимизации памяти хостов ESXi, объясняемые на плакате:

• Memory ballooning
• Transparent page sharing
• Memory Compression
• Host Swapping

Есть также интересная картинка с объяснением параметров вывода esxtop, касающихся памяти (кликабельно):

Пишут, что администраторы VMware vSphere скачивают его, распечатывают в формате A2 и смотрят на него время от времени, как на новые ворота. Таги: VMware, vSphere, Memory, ESX, esxtop, VMachines, Whitepaper, Diagram

Symantec Veritas Dynamic Multi-Pathing for VMware vSphere - еще один продукт для управления путями.

Вчера мы писали об архитектуре VMware PSA, позволяющей встраивать в VMware ESXi ПО для управления путями, а сегодня расскажем еще об одном продукте, совсем недавно анонсированном компанией Symantec - Veritas Dynamic Multi-Pathing for VMware vSphere 6.0.

Ключевые особенности продукта от Symantec - возможность динамической балансировки запросов ввода-вывода с хоста по нескольким путям одновременно, поддержка работы с основными дисковыми массивами, представленными на рынке, и возможность учитывать характеристики хранилищ (RAID, SSD, Thin Provisioning).

Как можно узнать из нашей статьи про PSA, Veritas Dynamic Multi-Pathing (DMP) - это MPP-плагин для хостов ESXi:

Veritas DMP позволяет интеллектуально балансировать нагрузку с хостов ESXi в SAN, обеспечивать непрерывный мониторинг и статистику по путям в реальном времени, автоматически восстанавливать путь в случае сбоя и формировать отчетность через плагин к vCenter обо всех хранилищах в датацентре. Что самое интересное - это можно будет интегрировать с физическим ПО для доступа по нескольким путям (VxVM) в единой консоли.

Всего в Veritas DMP существует 7 политик для балансировки I/O-запросов, которые могут быть изменены "на лету" и позволят существенно оптимизировать канал доступа к хранилищу по сравнению со стандартным плагином PSP от VMware. Кстати, в терминологии Symantec, этот продукт называется - VxDMP.

Стоимость этой штуки - от 900 долларов за четырехъядерный процессор хоста (цена NAM). Полезные ссылки:

• Hardware Compatibility List
• Veritas™ Dynamic Multi-Pathing for VMware Administrator's Guide 6.0
• Veritas™ Dynamic Multi-Pathing for VMware Release Notes 6.0
• Veritas™ Dynamic Multi-Pathing for VMware Installation Guide 6.0

Скачать Symantec Veritas Dynamic Multi-Pathing можно по этой ссылке, но только обладая ключиком.

Как знают все администраторы VMware vSphere, виртуальный диск виртуальной машины представляется как минимум в виде двух файлов:

• <имя ВМ>.vmdk - заголовочный, он же индексный, он же файл-дескриптор виртуальго диска, который содержит информацию о геометрии диска, его тип и другие метаданные
• <имя ВМ>-flat.vmdk - непосредственно диск с данными ВМ

Практика показывает, что нередки ситуации, когда администраторы VMware vSphere теряют заголовочный файл VMDK по некоторым причинам, иногда необъяснимым, и остается только диск с данными ВМ (неудивительно, ведь в него идет запись, он залочен).

Ниже приведена краткая процедура по восстановлению дескрипторного VMDK-файла для существующего flat-VMDK, чтобы восстановить работоспособность виртуальной машины. Подробную инструкцию можно прочитать в KB 1002511.

Итак, для тех, кто любит смотреть видеоинструкции:

Для тех, кто не любит:

1. Определяем точный размер в байтах VMDK-диска с данными (чтобы геометрия нового созданного дескриптора ему соответствовала):

ls -l <имя диска>-flat.vmdk

2. Создаем новый виртуальный диск (цифры - это полученный размер в байтах, тип thin для экономии места, lsilogic - контроллер):

vmkfstools -c 4294967296 -a lsilogic -d thin temp.vmdk

3. Переименовываем дескрипторный VMDK-файл созданного диска в тот файл, который нам нужен для исходного диска. Удаляем только что созданный пустой диск данных, который уже не нужен (temp-flat.vmdk).

4. Открываем переименованный дескрипторный файл VMDK и меняем выделенные жирным строчки:

# Disk DescriptorFile
version=1
CID=fb183c20
parentCID=ffffffff
createType="vmfs"

# Extent description
RW 8388608 VMFS "vmdisk0-flat.vmdk"

# The Disk Data Base
#DDB

ddb.virtualHWVersion = "4"
ddb.geometry.cylinders = "522"
ddb.geometry.heads = "255"
ddb.geometry.sectors = "63"
ddb.adapterType = "lsilogic"
ddb.thinProvisioned = "1"

То есть, меняем просто имя flat VMDK-файла и убираем строчку о том, что диск thin provisioned, если он у вас изначально был flat.

Все - машину можно запускать.

У нас уже есть серия статей про снапшоты виртуальных машин, добавим к ней еще одну. Мы не освещали тот факт, что для бизнес-критичных приложений (Tier 1) поддержка снапшотов может не предоставляться со стороны производителя программного обеспечения. Это еще один факт из серии "почему снапшоты это плохо".

Давайте обратимся к статье блоггера Matt Liebowitz, который привел цитаты из официальных источников Microsoft про предоставление поддержки для приложений Exchange и SQL, работающих в виртуальных машинах.

Microsoft Exchange 2010 System Requirements:

Some hypervisors include features for taking snapshots of virtual machines. Virtual machine snapshots capture the state of a virtual machine while it's running. This feature enables you to take multiple snapshots of a virtual machine and then revert the virtual machine to any of the previous states by applying a snapshot to the virtual machine. However, virtual machine snapshots aren't application aware, and using them can have unintended and unexpected consequences for a server application that maintains state data, such as Exchange. As a result, making virtual machine snapshots of an Exchange guest virtual machine isn't supported.

Support policy for SQL Server running in a hardware virtualization environment (covers all versions):

Virtualization Snapshots for Hyper-V or for any virtualization vendor are not supported to use with SQL Server in a virtual machine. It is possible that you may not encounter any problems when using snapshots and SQL Server, but Microsoft will not provide technical support to SQL Server customers for a virtual machine that was restored from a snapshot.

Конечно же, интереснее всего не сами снапшоты виртуальных машин в VMware vSphere или Hyper-V, которые редко используются в производственных средах, а то, что для резервного копирования эти снапшоты используются любым продуктом для резервного копирования, который архивирует работающую виртуальную машину целиком (например, Veeam Backup and Replication). Иначе просто нельзя забрать файл виртуального диска, в который идет запись.

Таким образом, мы получаем, что для Microsoft Exchange и SQL поддержку пользователи могут не получить, особенно это касается случаев восстановления резервных копий, которые могут некорректно работать. Учитывая, что приложения эти, зачастую, являются одними из самых критичных для предприятия - вопрос поддержки оказывается весьма актуальным.

Также, важно отметить, что поддержка приложением резервного копирования функций VSS writer (в том же Veeam) не гарантирует вам поддержки со стороны Microsoft, что также логично, поскольку последняя не может отвечать за сторонних разработчиков.

Ну и Мэт отмечает, что для тех пользователей, у кого есть Microsoft Premier support agreement, техподдержка Microsoft попробует сделать усилия, чтобы решить проблему со снапшотами если она вдруг возникнет.

И последний, но немаловажный момент: в Veeam Backup and Replication, начиная с 5-й версии, есть функция SureBackup, позволяющая проверить резервные копии на работоспособность и готовность к восстановлению, без реального восстановления в продуктивную среду. Вот для таких случаев как тестирование Tier 1 приложений может и пригодиться эта штука.

Поскольку виртуальная машина может состоять из множества файлов (виртуальные диски, конфигурация и т.п) и не имеет формальных правил ее описания для переносимости между платформами, был придуман формат OVF ( Open Virtualization Format). Он представляет собой унифицированный формат распространения готовых виртуальных машин (Virtual Appliances) - виртуальных модулей, которые можно просто скачать и импортировать на платформу виртуализации VMware vSphere или какую-нибудь другую.

В vSphere Client делается это так:

А как наоборот сделать из большого набора файлов vmdk и прочего виртуальную машину в формате OVF? Можно воспользоваться встроенной функцией vSphere Client - Export OVF Template:

Но ее возможности весьма невелики. Намного интереснее - воспользоваться утилитой OVF Tool от VMware, которая позволяет создавать виртуальные модули из виртуальных машин и виртуальных сервисов (vApp) для различных платформ виртуализации. Также утилита может и импортировать виртуальные модули в VMware vSphere.

Простейший способ ее использования - это запаковать машину в OVF, указав путь к vmx-файлу и путь к целевому ovf-файлу:

ovftool.exe <path to vmx> <path to ovf>

Получится вот такой симпатичный набор, который дальше можно выкладывать для скачивания или переносить на флэшках:

Ну а дальше есть куча опций по созданию OVF-пакета, которые можно вывести командой:

ovftool.exe -h

Далее нужно изучать документацию, чтобы построить свой Virtual Appliance по следующим ссылкам:

• Open Virtualization Format Tool
• OVF Tool Documentation
• Virtual Appliances

Как многие из вас знают, в среде VMware vSphere есть специализированные виртуальные машины, которую выполняют служебные функции, специфические для виртуальной инфраструктуры. К ним, например, можно отнести, виртуальные агенты (Agent VMs) - машины, предназначенные для того, чтобы присутствовать на хосте всегда (т.е. не участвовать в DRS/DPM) и обслуживать другие ВМ. Хороший пример - это антивирусные виртуальные модули (Virtual Appliance), которые сейчас есть у Trend Micro и Касперского и которые работают через vShield Endpoint и VMsafe API:

Логично предположить, что эти виртуальные машины в среде VMware vSphere надо обрабатывать как-то по-особенному. Это так и происходит. Давайте посмотрим, как это делается:

1. Платформа vSphere помечает внутри себя такие виртуальные машины как виртуальные агенты (Agent VMs).

2. Поскольку виртуальный агент должен предоставлять сервис для других виртуальных машин, агенские ВМ, в случае сбоя, на каждом хосте запускаются в первую очередь, чтобы не оставить никого без этого сервиса.

Таким образом, в случае сбоя порядок загрузки ВМ на хосте ESXi следующий:

• стартуют виртуальные агенты
• запускаются Secondary виртуальные машины для тех, которые защищены технологией Fault Tolerance
• поднимаются виртуальные машины с высоким, средним и низким приоритетом, соответственно

3. Механизм VMware DRS/DPM, осуществляющий балансировку виртуальных машин по хостам средствами vMotion и экономию электропитания серверов средствами их отключения при недогрузке датацентра, также в курсе о виртуальных агентах. Поэтому здесь следующее поведение:

• DRS учитывает Reservations, заданные для агентов, даже в том случае, когда они выключены
• для режимов обслуживания (maintenance mode) и Standby - виртуальные агенты никуда с хоста автоматически не мигрируют
• виртуальные агенты должны быть доступны на хосте перед тем, как там будут включены обычные ВМ или они туда будут смигрированы

Источники: тут и тут.

Все разработчики, но не все администраторы VMware vSphere 5 знают, что есть такой инструмент Managed Object Browser (MOB), который позволяет просматривать структуру программных объектов хоста или сервера vCenter и вызывать различные методы через API.

Работать с MOB через браузер можно двумя способами (потребуется ввод административного пароля):

• По ссылке на хост ESXi: http://<имя хоста>/mob
• По ссылке на сервер vCenter: http://<имя vCenter>/mob

Вот, например, методы для работы с виртуальными дисками:

Вообще, полазить там для администратора будет интересно и полезно - можно узнать много нового о том, какие свойства есть у различных объектов vSphere. И прямо оттуда можно создавать различные объекты виртуальной среды с их параметрами.

Ну а пост этот о том, что в VMware vSphere 5 появился еще один раздел MOB - mobfdm, доступный по ссылке:

http://<имя хоста>/mobfdm

Этот MOB позволяет вызывать методы Fault Domain Manager, отвечающего за работу механизма VMware HA. Там можно узнать много интересного: какие хосты master и slave, список защищенных ВМ, Heartbeat-датасторы, состояние кластера и многое другое.

Покопайтесь - это интересно.

Аппаратура виртуализации ЦП разрабатывалась в рамках концепции монопольного использования. Это означает, что только единственный Гипервизор может использовать ее, запустить Гипервизор в задаче другого Гипервизора невозможно. Это в теории, но практика требует во многих случаях все-таки наличия нескольких гипервизоров одновременно и это абсолютно неисследованная область, по крайней мере, в публичных источниках. Гипервизор, могущий запустить в своих задачах другие гипервизоры, редкий зверь, упоминания о них встречаются, но таких работающих программ нет. Единственное внятное упоминание о такой «матрешке» из гипервизоров, это некий хитрый гипервизор Рутковской. Его реальная работоспособность в связке с коммерческими системами виртуализации мне неизвестна.

Компания Microsoft, как и планировала, на днях выпустила сборки настольной и серверной версии операционных систем Windows 8 Consumer Preview и Windows 8 Server Beta, соответственно. В обе версии включен гипервизор Hyper-V 3.0, о возможностях которого мы уже писали тут. Также доступна для скачивания бесплатная платформа виртуализации Hyper-V Server 8 Beta на базе этого гипервизора.

Напомним основные улучшения Hyper-V 3.0 по сравнению с его младшей версией в Windows Server 2008 R2:

Кроме того, в клиенской версии Windows 8 возможности Hyper-V 3.0 будут такими же, как и в серверной версии:

Важное отличие только в том, что в клиентской Windows 8 на хосте обязательно наличие поддержки Second Level Address Translation (SLAT), а в серверной - нет.

Итак, ссылки на скачивание и документацию:

• Windows 8 Consumer Preview (скачать, руководство, FAQ, ISO)
• Windows 8 Server Beta (скачать, материалы, что нового)
• Hyper-V Server 8 Beta (скачать)

Управлять Windows 8 Server Beta можно с рабочей станции Windows 8 Consumer Preview с помощью пакета RSAT. Ну и напоминаем, что инструкция по запуску этих ОС на VMware vSphere действует и для этих билдов.

Как вы знаете, еще в VMware vSphere 4.1 появилась возможность "пробрасывать" USB-устройства сервера в виртуальные машины (USB device passthrough). В VMware vSphere 5 эти возможности еще были несколько улучшены за счет добавления поддержки устройств для проброса и от клиента (+USB 3.0), а не только от сервера. В этой заметке приведем основные особенности и условия использования USB-устройств в виртуальных машинах на серверах ESXi.

Для начала простые правила при пробросе USB-устройств сервера (Host-Connected USB Passthrough):

• одно USB-устройствo может быть проброшено только в одну ВМ, для одной ВМ может быть использовано до 20 устройств
• Для работы проброса необходима версия Virtual Hardware 7 или выше (в vSphere 5 - восьмая версия)
• Понятное дело, на хосте должен быть USB-контроллер. USB arbitrator хоста ESXi может управлять 15-ю контроллерами
• Для ВМ с привязанными к ним USB-устройствами можно использовать vMotion, но мигрировать сами устройства нельзя
• Перед тем как использовать USB-устройство в ВМ, нужно добавить к ней USB-контроллер в настройках

Правила посложнее:

• Перед отключением проброшенного в ВМ USB-устройства рекомендуется отключать проброс контроллера в ВМ.
• Перед использованием функций Hot Add (memory, CPU) нужно отключать USB-устройства от ВМ, поскольку при добавлении ресурсов Hot Add устройства USB отключаются, что может привести к потере данных
• Виртуальная машина не может загружаться с проброшенного устройства USB
• Ну и наверное догадываетесь, что нельзя пробрасывать флэшку с самим ESXi
• Контроллер xHCI (для устройств USB 3.0) доступен пока только для Linux-систем (начиная с ядра 2.6.35), для Windows драйверов пока нет

Также отметим, что начиная с VMware vSphere 5.0, стала доступной возможность пробрасывать USB-устройства в ВМ от клиентов (Client-Connected USB Passthrough). Поскольку эта возможность реализована на уровне клиента vSphere Client, то, используя клиента пятой версии, можно пробрасывать USB-девайсы на ВМ, размещенные на ESX/ESXi 4.1.

Таким образом, получается следующая таблица поддержки интерфейсов USB и типов подключения устройств:

USB-контроллер можно добавить к виртуальной машине как из Sphere Client:

так и из vSphere Web Client:

Вопреки расхожему мнению, поддержка USB-устройств в виртуальных машинах VMware vSphere весьма ограничена. Вот полный список поддерживаемых устройств из KB:

То есть всего ничего - эти модели были протестированы чисто чтобы табличку заполнить. Все что за пределами этого списка следует тестировать самостоятельно, в этом случае вопросы в техподдержку VMware задавать не следует.

Как вы знаете, в VMware vSphere 5 есть возможность динамической миграции хранилищ виртуальных машин - Storage vMotion. Эта возможность позволяет не только без простоя перенести виртуальные машины между хранилищами и их LUN, но и изменять формат результирующего виртуального диска (thin или thick).

В этой заметке мы рассмотрим один из интересных аспектов миграции Storage vMotion - перенесение томов RDM (Raw Device Mapping) виртуальных машин, работающих в режиме виртуальной и физической совместимости (physical and virtual RDMs).

Также перенос хранилища виртуальной машины мы можем сделать не только в "горячем" режиме, но и в "холодном" с помощью функции Cold Migration (для выключенной ВМ). В этом случае мы также можем выбрать формат виртуального диска результирующей ВМ. Давайте посмотрим как эти условия влияют на перенос RDM томов во всех случаях.

Перенос включенных ВМ с физическим RDM (pRDM) средствами Storage vMotion:

• Если вы пытаетесь изменить формат результирующего диска - Storage vMotion будет сделать нельзя.
• Если вы не пытаетесь изменить формат - будет перемещен маппинг-файл pRDM тома с исходного VMFS-хранилища на результирующее. Данные останутся на исходном LUN.

Перенос включенных ВМ с виртуальным RDM (vRDM) средствами Storage vMotion:

• Если вы изменяете формат результирующего диска (в advanced view) - том vRDM будет сконвертирован в VMDK-диск на целевом томе VMFS.
• Если вы не изменяете формат - будет перемещен маппинг-файл vRDM тома с исходного VMFS-хранилища на результирующее. Данные останутся на исходном LUN.

Перенос выключенных ВМ с физическим RDM (pRDM) средствами Cold Migration:

• Если вы изменяете формат результирующего диска (в advanced view) - том pRDM будет сконвертирован в VMDK-диск на целевом томе VMFS.
• Если вы не изменяете формат - будет перемещен маппинг-файл pRDM тома с исходного VMFS-хранилища на результирующее. Данные останутся на исходном LUN.

Перенос выключенных ВМ с виртуальным RDM (vRDM) средствами Cold Migration:

• Если вы изменяете формат результирующего диска (в advanced view) - том vRDM будет сконвертирован в VMDK-диск на целевом томе VMFS.
• Если вы не изменяете формат - будет перемещен маппинг-файл vRDM тома с исходного VMFS-хранилища на результирующее. Данные останутся на исходном LUN.

Таким образом, у нас получается 3 ситуации, когда исходный RDM-том конвертируется в VMDK-диск на целевом томе, при этом в мастере миграции вас никто об этом не предупреждает.

Также есть еще один аспект при миграции таких томов. Если исходный RDM-том находился в режиме Independent Persistent (а pRDM обязательно в этом режиме находится), то, как следует из свойств этого диска, он не участвует в создании снапшотов ВМ.

После миграции, если он будет сконвертирован в vmdk-файл, то он также останется в этом режиме:

А это значит софт для резервного копирования виртуальных машин не будет бэкапить такой диск, поскольку он не участвует в создании снапшота. Учитывайте этот момент.

О снапшотах виртуальных машин VMware vSphere мы уже много писали (например, можно пискать по тэгу "Snapshot"). Постараемся в этой заметке просуммировать информацию о том, что из себя представляют файлы снапшотов виртуальных машин vSphere 5 и как они обрабатываются.

Для того, чтобы снять снапшот виртуальной машины (virtual machine snapshot), можно кликнуть на ней правой кнопкой в vSphere Client и выбрать соответствующий пункт "Take Snapshot" из контекстного меню:

Далее появится окно снятия снапшота ВМ:

Обратите внимание на опцию "Snapshot the virtual machine's memory". Если эту галку убрать, то снапшот не будет содержать состояние памяти виртуальной машины, т.е. при откате к нему ВМ будет в выключенном состоянии. Плюс такого снапшота - он создается намного быстрее, поскольку не надо сохранять память машины в отдельный файл.

Вторая опция - это возможность "заморозки" файловой системы виртуальной машины на время создания снапшота. Она доступна только при условии установленных в гостевой ОС VMware Tools, в составе которых идет Sync Driver. Эта функциональность нужна для создания консистентного состояния виртуальной машины для снапшота на уровне файловой системы, что особенно необходимо при создании резервных копий (используют все системы резервного копирования для виртуализации, например, Veeam Backup and Replication). Данная возможность (quiesce) поддерживается не всегда - об условиях ее применения можно прочитать тут.

После создания снапшота заглянем в Datastore Browser на хосте VMware ESXi через vSphere Client:

Выделенные зеленым объекты - это абстрации двух снапшотов виртуальных машин. Чтобы понять, что собой представляют эти абстрации, откроем каталог с виртуальной машины в консоли (Putty по SSH):

Здесь мы уже видим, что снапшот на самом деле - это набор из четырех файлов:

• <имя ВМ>-[шесть цифр]-delta.vmdk - файл данных диска отличий от базового диска
• <имя ВМ>-[шесть цифр].vmdk - заголовочный файл
• <имя ВМ>.vmsd - текстовый файл с параметрами снапшота (связи в дереве, SCSI-нода, время создания и т.п.)
• <имя ВМ>.vmsn - файл с сохраненной памятью виртуальной машины

Самый главный файл - это, конечно, <имя ВМ>-[шесть цифр]-delta.vmdk. Он содержит блоки данных хранимые в формате так называемых redo-логов (он же дочерний диск - child disk). Он же sparse-диск, то есть диск, который использует технологию Copy-On-Write (COW) при работе с данными. Идея технологии copy-on-write — при копировании областей данных создавать реальную копию только когда ОС обращается к этим данным с целью записи. Таким образом, этот виртуальный диск содержит только измененные от родительского диска области данных (delta).

По умолчанию размер COW-операции составляет 64 КБ, что эквивалентно 128 секторам (подробнее). Но сам снапшот растет блоками данных по 16 МБ. То есть запись 64 КБ данных исходного диска может породить прирост 16 МБ данных в диске снапшота.

Следующий интересный тип файла - <имя ВМ>.vmsd. Это обычный текстовый файл, который можно открыть в редакторе и увидеть все отношения между родительским и дочерними дисками, а также другую интересную информацию:

Ну и последнее - это память виртуальной машины, хранящаяся в файле <имя ВМ>.vmsn. Его, понятное дело, может не быть, если вы создавали снапшот выключенной ВМ или убрали галку, о которой написано в самом начале.

По умолчанию снапшоты складываются в папку на VMFS-томе, где лежит виртуальная машина. Но это размещение можно сменить, поменяв рабочую папку (Working Directory) в настройках виртуальной машины через vSphere Client или в vmx-файле, для чего нужно добавить или поменять строчку:

workingDir="/vmfs/volumes/SnapVolume/Snapshots/"

Кстати, эта же папка задает и размещение файла подкачки ВМ (*.vswp). Если вы его хотите оставить на прежнем месте, нужно добавить строчку:

sched.swap.dir = "/vmfs/volumes/VM-Volume1/MyVM/"

Ну и напоследок, какие операции поддерживаются для виртуальных машин со снапшотами:

Более подробную информацию о снапшотах можно найти в KB 1015180.

Ну и небольшая подборка ссылок по траблшутингу снапшотов в VMware vSphere:

• Best practices for virtual machine snapshots in the VMware environment
• Creating a snapshot for a virtual machine fails with the error: File is larger than maximum file size supported (1012384)
• Delete All snapshot operation results in a Consolidate Helper snapshot when a datastore has insufficient disk space (1003302)
• Taking a snapshot with virtual machine memory stuns the virtual machine while the memory is written to disk (1013163)
• Committing snapshots fails with the error: Too many levels of redo logs (1004545)
• Why snapshot removal can stop a virtual machine for a long time (1002836)
• Large snapshot delete operations time out in VirtualCenter (1004932)
• Commands to monitor snapshot deletion (1007566)
• Consolidating snapshots via the command line (1007849)
• Unable to take a quiesced VMware snapshot of a virtual machine (1009073)

И отдельно выделим вот эту потрясающую библию снапшотов: Troubleshooting Virtual Machine snapshot problems.

Если вам не терпится посмотреть на то, что из себя представляет новая версия настольной ОС Microsoft Windows 8, то есть способ это сделать, не мучая физический компьютер. Если раньше официальная статья KB 2006859 говорила о том, что в виртуальной машине Windows 8 поставить нельзя, то теперь вышел патч для vSphere 5, а William Lam описал способ развертывания гостевой ОС.

Способ очень прост:

1. Устанавливаем на хост VMware ESXi патч ESXi500-201112001 (patch02) из VMware patch repository.

2. Создаем виртуальную машину, указав в качестве гостевой ОС Windows 7 или Windows 2008 R2.

3. Заходим в настройки ВМ "Hardware->Video Card" и включаем "3D graphics support" (нужно для установки VMware Tools).

4. Привязываем к ВМ ISO-образ Windows 8 и запускаем установку.

В итоге Windows 8 в виртуальной машине vSphere 5 работает отлично:

Ну а Windows 8 Developer Preview можно скачать по этой ссылке. Как мы уже писали, бета-версию Windows 8 обещают к концу февраля, а окончательный релиз - к концу года.

Мы уже писали о том, что в новом продукте StarWind Native SAN for Hyper-V для создания отказоустойчивых хранилищ Hyper-V с использованием всего 2-х серверов присутствует возможность резервного копирования виртуальных машин под названием VM Backup. Давайте заглянем немного в процесс резервного копирования StarWind Native SAN. В плане работы с плагином VM Backup сначала появляются следующие задачи:

Напомним, что совсем недавно компания «Код Безопасности» выпустила технический релиз новой версии vGate R2 с поддержкой VMware 5. Сейчас она проходит инспекционный контроль во ФСТЭК для получения соответствующих сертфикатов, наличие которых позволит вашей организации пройти процедуру аттестации или проверки со стороны государственных органов. Сегодня мы более подробно расскажем о новых политиках настройки безопасной среды виртуализации.

В данной статье объединены все общедоступные на сегодняшний день расширенные настройки кластера VMware HA (с учетом нововведений механизма) для обеспечения высокой доступности сервисов в виртуальных машинах VMware vSphere 5.0 и более ранних версий. Отказоустойчивость достигается двумя способами: средствами VMware HA на уровне хостов ESXi (на случай отказов оборудования или гипервизора) и средствами VMware VM Monitoring (зависание гостевой операционной системы).

На каждом хосте службой VMware HA устанавливается агент Fault Domain Manager (FDM), который пришел на смену агентам Legato AAM (Automated Availability Manager). В процессе настройки кластера HA один из агентов выбирается как Master, все остальные выполняют роль Slaves (мастер координирует операции по восстановлению, а в случае его отказа выбирается новый мастер). Теперь больше нет primary/secondary узлов. Одно из существенных изменений VMware HA - это Datastore Heartbeating, механизм, позволяющий мастер-серверу определять состояния хост-серверов VMware ESXi, изолированных от сети, но продолжающих работу с хранилищами.

Задать Advanced Options для VMware HA (иногда их называют Advanced Settings) можно, нажав правой кнопкой на кластер в vSphere Client и далее выбрав пункт "Edit Settings", где уже нужно вводить их как указано на картинке:

Список Advanced Options для VMware HA, действующих только в vSphere 5.0:

• das.ignoreinsufficienthbdatastore - определяет, будет ли игнорировано сообщение о количестве имеющихся Heartbeat-хранилищ, которое меньше сконфигурированного в настройке das.heartbeatdsperhost (по умолчанию - это 2 хранилища). То есть если Heartbeat-хранилище присутствует только одно - будет выведено следующее сообщение:
  
  Выставление значения этого параметра в true уберет это предупреждение из vSphere Client.
• das.heartbeatdsperhost - определяет количество Heartbeat-хранилищ, которое можно регулировать данной настройкой (допустимые значения - от 2 до 5). По умолчанию, данное значение равно 2.
• das.config.log.maxFileNum - определяет количество лог-файлов, в пределах которого будет происходить их ротация.
• das.config.log.maxFileSize - максимальный размер лог-файла, задаваемый в байтах.
• das.config.log.directory - путь для хранения лог-файлов VMware HA. При задании настроек логов следует руководствоваться следующей таблицей (подробнее читайте тут на последних страницах):
  
• das.config.fdm.deadIcmpPingInterval - интервал между пингами по протоколу ICMP для определения доступности Slave-хоста ESXi в сети со стороны Master, в случае, если нет коммуникации с FDM-агентом Slave-хоста (используется, чтобы определить - сломался агент FDM или хост вышел из строя). По умолчанию задано значение 10 (секунд).
• das.config.fdm.icmpPingTimeout - таймаут, который хост (мастер) ожидает перед получением ответа на пинг, при неполучении которого он считает один из хостов недоступным из сети (то есть время, которое он дает для ответа на пинг, после чего начинаются операции по восстановлению ВМ). По умолчанию задано значение 5 (секунд).
• das.config.fdm.hostTimeout - таймаут, который мастер ожидает после события неполученного хартбита от FDM-агента хоста после чего он определяет является ли хост отказавшим (dead), изолированным (isolated) или в другом сегменте разделенной сети (partitioned). По умолчанию задано значение 10 (секунд). Сами же хартбиты между мастером и slave-хостами посылаются каждую секунду.
• das.config.fdm.stateLogInterval - частота записи состояния кластера в лог-файл. По умолчанию выставлено в 600 (секунд).
• das.config.fdm.ft.cleanupTimeout - когда сервер vCenter инициирует запуск Secondary-машины, защищенной с помощью Fault Tolerance, он информирует мастера HA о том, что он начал этот процесс. Далее мастер ждет время, выставленное в этой настройке, и определяет запустилась ли эта виртуальная машина. Если не запустилась - то он самостоятельно инициирует ее повторный запуск. Такая ситуация может произойти, когда во время настройки FT вдруг вышел из строя сервер vCenter. По умолчанию задано значение 900 (секунд).
• das.config.fdm.storageVmotionCleanupTimeout - когда механизм Storage vMotion перемещает виртуальную машину с/на хосты ESX 4.1 или более ранней версии, может возникнуть конфликт, когда HA считает, что это не хранилище ВМ переместилось, а сама ВМ отказала. Поэтому данная настройка определяет, сколько времени мастеру нужно подождать, чтобы завершилась операция Storage vMotion, перед принятием решения о перезапуске ВМ. См. также нашу заметку тут. По умолчанию задано значение 900 (секунд).
• das.config.fdm.policy.unknownStateMonitorPeriod - определяет сколько агент мастера ждет отклика от виртуальной машины, перед тем как посчитать ее отказавшей и инициировать процедуру ее перезапуска.
• das.config.fdm.event.maxMasterEvents - определяет количество событий, которые хранит мастер операций HA.
• das.config.fdm.event.maxSlaveEvents - определяет количество событий, которые хранят Slave-хосты HA.

Список Advanced Options для VMware HA в vSphere 5.0 и более ранних версиях:

• das.defaultfailoverhost - сервер VMware ESXi (задается короткое имя), который будет использоваться в первую очередь для запуска виртуальных машин в случае сбоя других ESXi. Если его емкости недостаточно для запуска всех машин – VMware HA будет использовать другие хосты.
• das.isolationaddress[n] - IP-адрес, который используется для определения события изоляции хостов. По умолчанию, это шлюз (Default Gateway) сервисной консоли. Этот хост должен быть постоянно доступен. Если указано значение n, например, das.isolationaddress2, то адрес также используется на проверку события изоляции. Можно указать до десяти таких адресов (диапазон n от 1 до 10).
• das.failuredetectioninterval - значение в миллисекундах, которое отражает время, через которое хосты VMware ESX Server обмениваются хартбитами. По умолчанию равно 1000 (1 секунда).
• das.usedefaultisolationaddress - значение-флаг (true или false, по умолчанию - true), которое говорит о том, использовать ли Default Gateway как isolation address (хост, по которому определяется событие изоляции). Параметр необходимо выставить в значение false, если вы планируете использовать несколько isolation-адресов от das.isolationaddress1 до das.isolationaddress10, чтобы исключить шлюз из хостов, по которым определяется событие изоляции.
• das.powerOffonIsolation - значение флаг (true или false), используемое для перекрытия настройки isolation response. Если установлено как true, то действие «Power Off» - активно, если как false - активно действие «Leave powered On». Неизвестно, работает ли в vSphere 5.0, но в более ранних версиях работало.
• das.vmMemoryMinMB - значение в мегабайтах, используемое для механизма admission control для определения размера слота. При увеличении данного значения VMware HA резервирует больше памяти на хостах ESX на случай сбоя. По умолчанию, значение равно 256 МБ.
• das.vmCpuMinMHz - значение в мегагерцах, используемое для механизма admission control для определения размера слота. При увеличении данного значения VMware HA резервирует больше ресурсов процессора на хостах ESX на случай сбоя. По умолчанию, значение равно 256 МГц (vSphere 4.1) и 32 МГц (vSphere 5).
• das.conservativeCpuSlot - значение-флаг (true или false), определяющее как VMware HA будет рассчитывать размер слота, влияющего на admission control. По умолчанию установлен параметр false, позволяющий менее жестко подходить к расчетам. Если установлено в значение true – механизм будет работать как в VirtualCenter 2.5.0 и VirtualCenter 2.5.0 Update 1. Неизвестно, осталась ли эта настройка актуальной для vSphere 5.0.
• das.allowVmotionNetworks - значение-флаг, позволяющее или не позволяющее использовать физический адаптер, по которому идет трафик VMotion (VMkernel + VMotion Enabled), для прохождения хартбитов.Используется только для VMware ESXi. По умолчанию этот параметр равен false, и сети VMotion для хартбитов не используются. Если установлен в значение true – VMware HA использует группу портов VMkernel с включенной опцией VMotion.
• das.allowNetwork[n] – имя интерфейса сервисной консоли (например, ServiceConsole2), который будет использоваться для обмена хартбитами. n – номер, который отражает в каком порядке это будет происходить. Важно! - не ошибитесь, НЕ пишите das.allowNetworkS.
• das.isolationShutdownTimeout - значение в секундах, которое используется как таймаут перед срабатыванием насильственного выключения виртуальной машины (power off), если не сработало мягкое выключение из гостевой ОС (shutdown). В случае выставления isolation response как shutdown, VMware HA пытается выключить ее таким образом в течение 300 секунд (значение по умолчанию). Обратите внимание, что значение в секундах, а не в миллисекундах.
• das.ignoreRedundantNetWarning - значение-флаг (true или false, по умолчанию false), который при установке в значение false отключает нотификацию об отсутствии избыточности в сети управления («Host xxx currently has no management network redundancy»). По умолчанию установлено в значение false.

Настройки VM Monitoring для VMware HA платформы vSphere 5.0 и более ранних версий:

• das.vmFailoverEnabled - значение-флаг (true или false). Если установлен в значение true – механизм VMFM включен, если false – выключен. По умолчанию установлено значение false.
• das.FailureInterval - значение в секундах, после которого виртуальная машина считается зависшей и перезагружается, если в течение этого времени не получено хартбитов. По умолчанию установлено значение 30.
• das.minUptime - значение в секундах, отражающее время, которое дается на загрузку виртуальной машины и инициализацию VMware Tools для обмена хартбитами. По умолчанию установлено значение 120.
• das.maxFailures - максимальное число автоматических перезагрузок из-за неполучения хартбитов, допустимое за время, указанное в параметре das.maxFailureWindow. Если значение das.maxFailureWindow равно «-1», то das.maxFailures означает абсолютное число отказов или зависаний ОС, после которого автоматические перезагрузки виртуальной машины прекращаются, и отключается VMFM. По умолчанию равно 3.
• das.maxFailureWindow - значение, отражающее время в секундах, в течение которого рассматривается значение параметра das.maxFailures. По умолчанию равно «-1». Например, установив значение 86400, мы получим, что за сутки (86400 секунд) может произойти 3 перезапуска виртуальной машины по инициативе VMFM. Если перезагрузок будет больше, VMFM отключится. Значение параметра das.maxFailureWindow может быть также равно «-1». В этом случае время рассмотрения числа отказов для отключения VMFM – не ограничено.

Настройки, которые больше не действуют в vSphere 5.0:

• das.failuredetectiontime

Работает только в vSphere 4.1 и более ранних версиях (см. ниже).

Раньше была настройка das.failuredetectiontime - это значение в миллисекундах, которое отражает время, через которое VMware HA признает хост изолированным, если он не получает хартбитов (heartbeats) от других хостов и isolation address недоступен. После этого срабатывает действие isolation response, которое выставляется в параметрах кластера в целом, либо для конкретной виртуальной машины. По умолчанию, значение равно 15000 (15 секунд). Рекомендуется увеличить это время до 60000 (60 секунд), если с настройками по умолчанию возникают проблемы в работе VMware HA. Если у вас 2 интерфейса обмена хартбитами - можно оставить 15 секунд.

В VMware vSphere 5, в связи с тем, что алгоритм HA был полностью переписан, настройка das.failuredetectiontime для кластера больше не акутальна.

Теперь все работает следующим образом (см. также новые das-параметры, которые были описаны выше).

Наступление изоляции хост-сервера ESXi, не являющегося Master (т.е. Slave):

• Время T0 – обнаружение изоляции хоста (slave).
• T0+10 сек – Slave переходит в состояние "election state" (выбирает "сам себя").
• T0+25 сек – Slave сам себя назначает мастером.
• T0+25 сек – Slave пингует адрес, указанный в "isolation addresses" (по умолчанию, это Default Gateway).
• T0+30 сек – Slave объявляет себя изолированным и вызывает действие isolation response, указанное в настройках кластера.

Наступление изоляции хост-сервера ESXi, являющегося Master:

• T0 – обнаружение изоляции хоста (master).
• T0 – Master пингует адрес, указанный в "isolation addresses" (по умолчанию, это Default Gateway).
• T0+5 сек – Master объявляет себя изолированным и вызывает действие isolation response, указанное в настройках кластера.

Как мы видим, алгоритм для мастера несколько другой, чтобы при его изоляции остальные хосты ESXi смогли быстрее начать выборы и выбрать нового мастера. После падения мастера, новый выбранный мастер управляет операциями по восстановлению ВМ изолированного хоста. Если упал Slave - то, понятное дело, восстановлением его ВМ управляет старый мастер. И да, помним, что машины будут восстанавливаться, только если в Isolation Responce стоит Shutdown или Power Off, чтобы хост мог их погасить.

• das.bypassNetCompatCheck

Работает только в vSphere 4.1 и более ранних версиях (см. ниже).

Это значение-флаг (true или false, по умолчанию false), который будучи установлен в значение true позволяет обойти дополнительную проверку на совместимость с HA. В VirtualCenter Update 2 была введена проверка на совместимость подсетей, по которым ходят хартбиты. Возникала ошибка: «HA agent on in cluster in has an error Incompatible HA Network: Consider using the Advanced Cluster Settings das.allowNetwork to control network usage». Теперь, если сети считаются несовместимыми с точки зрения HA, однако маршрутизируемыми – новая опция поможет осуществить корректную настройку кластера.

Если у вас в инфраструктуре несколько версий VMware vSphere (например, 4.1 и 5.0) или вы хотите поставить VMware Tools для тестирования или на старых серверах (хотя все VMware Tools можно скопировать с ESX напрямую), вам может оказаться полезной вот эта ссылка - http://packages.vmware.com/tools/esx/index.html.

Там все упорядочено по версиям VMware vSphere / ESX / ESXi:

Последняя версия VMware Tools находится в папке "latest". По свойствам папки легко обнаружить дату обновления.

Ну а на сервере VMware ESXi пакеты VMware Tools находятся тут - /vmimages/tools-isoimages/. Скопировать вы их можете с помощью Veeam FastSCP.

Ну и видео обновления VMware Tools - мало ли кому-то пригодится:

Интересное (но неофициальное) исследование на тему миграции на новую версию платформы VMware vSphere 5 опубликовано на блоге virtualgeek. Было опрошено 1935 респондентов. Напомним, что VMware vSphere 5 вышла в августе этого года.

Самый занимательный график - это ответы на вопрос "Какую версию VMware vSphere вы сейчас используете?" (допускалось более одного варианта ответа):

59,2% для vSphere 5 - это очень и очень большой показатель, учитывая выход продукта 4 месяца назад.

Полезен также график ответов на вопрос "Используете ли вы другие технологии виртуализации":

Ну Hyper-V понятно, но, фигасе, XenServer жжет. Неожиданно.

Далее вопрос о проценте виртуализованных серверов (но надо учитывать специфику исследования - отвечали люди, которые крутятся в сфере виртуализации). График в лучших традициях Чурова, но автор говорит, что результат где-то 86%.

Далее - тоже интереснейшая тема. Системы хранения каких вендоров используют под виртуализацию:

EMC на высоте - молодцы. Но, по-моему, автор из EMC, поэтому тоже надо на это делать скидку.

Ну и теперь - ответьте на вопросы для нашего небольшого исследования:

Опрос VM Guru - 4 вопроса!

Результаты будут вывешены как только наберется репрезентативная выборка. Спасибо!

Хотим обратить ваше внимание на еще одно выгодное предложение в череде предновогодних скидок. Компании Softline и NetApp объявили о начале промо-акции по поставке систем хранения данных NetApp серии FAS2000 по выгодной цене.

Смотрите сами:

* Внимание! Цены указаны по курсу доллара ЦБ РФ на 29.11.2011. При покупке уточняйте стоимость у менеджера Softline.

Все системы хранения NetApp обеспечиваются трехлетней гарантией. Гарантия включает в себя сервис по замене вышедших из строя частей с доставкой по месту установки системы хранения на следующей рабочий день.

Надо сказать, что NetApp делает крутяцкие массивы, которые хорошо интегрированы с технологиями виртуализации VMware (см. тут, тут и тут). Кроме того, массивы NetApp обеспечивают поддержку технологии VAAI, которая во многих случаях в разы увеличивает производительность хранилищ виртуальных машин.

Получить консультацию и приобрести дисковые массивы NetApp вам поможет Роман Карнаухов (e-mail: netapp@softline.ru, тел. +7 (495) 232-0023, доб. 0959).

Мы уже много писали о продукте №1 - vGate R2 от компании Код Безопасности, обеспечивающем сертифицированную защиту виртуальных сред VMware vSphere, а также автоматическую настройку инфраструктуры виртуализации в соответствии с политиками, отражающими стандарты и руководящие документы в сфере ИБ. Долгое время существенной проблемой являлось то, что продукт не поддерживал новую версию платформы VMware vSphere 5, на которую постепенно переходят предприятия. Но проблемы больше нет - вышел vGate R2 с поддержкой vSphere 5.

Интересная штука обнаружилась в настройках мониторинга VMware vSphere. Оказывается в vSphere Client можно вывести информацию о том, сколько электроэнергии потребляет отдельно взятая виртуальная машина на хост-сервере ESXi.

Для этого необходимо выставить экспериментальную настройку Power.ChargeVMs в Advanced Options (которая по-умолчанию установлена в 0) в значение 1 на каждом из хостов ESXi:

После этого мы получим вот такой график в vSphere Client, отражающий потребление виртуальной машиной электричества (видимо, высчитывается из актуальных значений загрузки хоста по памяти и процессору). Кликабельно:

Для чего это нужно? Очевидно, что для таких продуктов, как VMware vCenter Chargeback, который высчитывает, во сколько обходится содержание различных объектов виртуальной инфраструктуры VMware vSphere. Кстати, недавно вышло обновление - VMware vCenter Chargeback 2.0.

Помните, мы писали, что снапшоты виртуальных машин в VMware vSphere - это плохо? Но иногда без них не обойтись - например, системы резервного копирования (например, Veeam Backup and Replication) вынуждены делать снапшоты, чтобы не прерывать работу виртуальной машины во время бэкапа.

Цель этой заметки - показать, что в VMware vSphere при работе со снапшотами все сделали несколько лучше, чем в предыдущей версии. Во-первых, смотрим это видео:

Мысль видео такова: если у вас некорректно завершилась операция по консолидации снапшотов, то в VMware vSphere 5 вам предлагается опция по консолидации, доступная из контекстного меню виртуальной машины:

То есть, теперь не надо терзать командную строку в случае появления проблем со снапшотами виртуальных машин.

Во-вторых, появилась опция по поиску виртуальных машин, нуждающихся в консолидации снапшотов, доступная из vSphere Client. Чтобы найти такие машины, нужно выбрать хост или кластер, перейти на вкладку "Virtual Machines" и по правой кнопке выбрать пункт "Needs Consolidation":

Ну и, в-третьих, в vSphere 5 полностью поддерживается "горячее" перемещение виртуальных машин между хранилищами средствами Storage vMotion, а также, само собой, между хостами средствами обычного vMotion.

Картинки честно украдены у Vladan'а Seget'а.